home *** CD-ROM | disk | FTP | other *** search
- OSI Interoperability Working Group
- Chairpersons: Ross Callon/DEC and Robert Hagens/U of Wisconsin
-
-
-
-
- CURRENT MEETING REPORT
- Reported by Ross Callon, Rob Hagens and Richard Colella
-
-
-
- AGENDA
-
-
- Monday, July 24th
-
- o Discussion and review of GOSIP V2
-
- Tuesday, July 25th
-
- o Inter-domain routing
-
- o Intra-domain routing
-
- Wednesday, July 26th
-
- o General Meeting
-
- 1. BSD 4.4 Update
-
- 2. Review of the CLNP Echo proposal
-
- 3. Review of GOSIP comments
-
- 4. Strategies for encapsulating CLNP in DoD IP
-
- o X.500
-
- o DEC DNS
-
-
- ATTENDEES
-
-
- 1. Abramowitz, Alyson/ala@hpindda.hp.com
-
- 2. Alberts, Charlie/charlie@banyan.banyan.com
-
- 3. Barker, Trudy/trudy@sri-nic.arpa
-
- 4. Bierbaum, Neal/bierbaum@vitalink.com
-
- 5. Blackwood, Craig/craig@hprnd.rose.hp.com
-
- 6. Brackenridge, Billy/brackenridge@isi.edu
-
- 7. Breslau, Lee/breslau@jerico.usc.edu
-
- 8. Brim, Scott/swb@devvax.tn.cornell.edu
-
-
-
- 1
- 9. Callon, Ross/callon@erlang.dec.com
-
- 10. Chapin, Lyman/lyman_chapin@dgc.mceo.dg.com
- 11. Chi, Debra/debee@sun.com
-
-
- 12. Colella, Richard/colella@osi3.ncsl.nist.gov
-
- 13. Collins, Mike/collins@ccc.mfecc.llnl.gov
-
- 14. Coltun, Rob/rcoltun@trantor.umd.edu
-
- 15. Deboo, Farokh/fjd@bridge2.esd.3com.com
-
- 16. Denny, Barbara/denny@sri.com
-
- 17. Doo, Way-Chi/wcd@bridge2.esd.3com.com
-
- 18. Farinacci, Dino/dino@bridge2.3com.com
-
- 19. Fedor, Mark/fedor@nisc.nyser.net
-
- 20. Fink, Bob/rlfink@lbl.gov
-
- 21. Forster, Jim/forster@cisco.com
-
- 22. Galvin, James/galvin@tis.com
-
- 23. Garcia-Luna, J. J./garcia@sri.com
-
- 24. Gary Ralls, Vicki/iruucp!sun!ntrlink!ralls
-
- 25. Gerich, Elise/epg@merit.edu
-
- 26. Gerlach, Chuck/cag@iwlcs.att.com
-
- 27. Gross, Martin/martin@protolaba.dca.mil
-
- 28. Hagens, Rob/hagens@cs.wisc.edu
-
- 29. Hollingsworth, Greg/gregh@gateway.mitre.org
-
- 30. Hytry, Tom/tlh@iwlcs.att.com
-
- 31. Ilnicki, Ski/ski
-
- 32. Jacobsen, Ole/ole@csli.stanford.edu
-
- 33. Jarza, Peggy
-
- 34. Jones, Bill/jones@nsipo.arc.nasa.gov
-
- 35. Jordt, Dan/danj@cac.washington.edu
-
- 36. Katz, Dave/dkatz@merit.edu
-
- 37. Kincl, Norman/kincl@iag.hp.com
-
- 38. Knopper, Mark/mak@merit.edu
-
- 39. Kullberg, Alan/akullberg@bbn.com
-
-
-
- 2
- 40. LaQuey, Tracy/tracy@emx.utexas.edu
-
- 41. Lebeck, Sue/lebeck@tandem.com
- 42. Lee, Young/youngl@jessica.stanford.edu
-
-
- 43. Lepp, Marianne/marianne@bbn.com
-
- 44. Leser, Norbert/nl@osf.org
-
- 45. Little, Mike/little@saic.com
-
- 46. Love, Paul/loveep@@sds.sdsc.edu
-
- 47. Lynch, Dan/lynch@isi.edu
-
- 48. Maas, Andy/maas@jessica.stanford.edu
-
- 49. Malkin, Gary/gmalkin@proteon.com
-
- 50. Mankin, Allison/mankin@gateway.mitre.org
-
- 51. Merritt, Don/don@brl.mil
-
- 52. Mockapetris, Paul/pvm@isi.edu
-
- 53. Mogul, Jeff/mogul@decwrl.dec.com
-
- 54. Montgomery, Doug/dougm@osi3.ncsl.nist.gov
-
- 55. Mundy, Russ/mundy@tis.com
-
- 56. Nitzan, Rebecca/nitzan@ccc.mfecc.llnl.gov
-
- 57. Ohle, Bill/ohle@osi.ncsl.nist.gov
-
- 58. Opalka, Zbigniew /zopalka@bbn.com
-
- 59. Oran, Dave/oran@oran.dec.com
-
- 60. Pak, Raylene/raylene@tardis.tymnet
-
- 61. Palmer, Howard/sun!iruucp!ntrlink!palmer
-
- 62. Pillalamarri, Shyam/shyam
-
- 63. Pugh, Jon/pugh@nmfecc.llnl.gov
-
- 64. Pugh, Rex/pugh@hprnd.rose.hp.com
-
- 65. Ramakrishnan, KK/rama
-
- 66. Reilly, Michael/reilly@atari.nac.dec.com
-
- 67. Reinstedler, Jim/jimr@ub.ubcom.com
-
- 68. Rekhter, Yakov/yakov@ibm.com
-
- 69. Replogle, Joel/replogle@ncsa.uiuc.edu
-
- 70. Reschly, Robert/reschly@brl.mil
-
-
-
- 3
- 71. Roberts, Mike/roberts@educom.edu
-
- 72. Roselinsky, Milt/cmcvax!milt@hub.ucsb.edu
- 73. Scanlan, Keely/keely@hprnd.rose.hp.com
-
-
- 74. Schoffstall, Martin/schoff@nisc.nyser.net
-
- 75. Schofield, Bruce/schofield@edn-vax.dca.mil
-
- 76. Sheridan, Jim/jsherida@ibm.com
-
- 77. Sklowear, Keith/sklower@okeeffe.berkeley.edu
-
- 78. Smith, Tom/toms@hprnd.rose.hp.com
-
- 79. Sollins, Karen/sollins@lcs.mit.edu
-
- 80. St. Johns, Mike/stjohns@beast.ddn.mil
-
- 81. Stahl, Mary/stahl@sri-nic.arpa
-
- 82. Steenstrup, Martha/msteenst@bbn.com
-
- 83. Stefferud, Einar/stef@nrtc.northrop.com
-
- 84. Sweeton, Jim/sweeton@merit.edu
-
- 85. Tausworthe, Bob/tozz@hpda.hp.com
-
- 86. Tharenos, Michael/tharenos@jessica.stanford.edu
-
- 87. Travis, Lance/cmt@apollo.com
-
- 88. Tsai, Howard/hst@mtuxo.att.com
-
- 89. Vance, L. Stuart/vance@tgv.com
-
- 90. Vaughan, Lynn/lynna@hprnd.rose.hp.cpm
-
- 91. Volk, Ruediger/rv@germany.eu.net
-
- 92. Wilder, Rick/rick@gateway.mitre.org
-
- 93. Youssef, Mary/mary@ibm.com
-
-
- MINUTES
-
- The meeting was convened by co-chairmen Ross Callon and Rob Hagens. The
- major issues discussed at this meeting included: GOSIP version 2,
- inter-domain and intra-domain routing, CLNP encapsulation, and directory
- services.
-
- GOSIP V2 COMMENTS (Monday)
-
- We went through the draft GOSIP version 2 document more or less front to
- back, and agreed on the following comments (to be submitted officially as
- OSIIWG comments):
-
-
-
- 4
- Congestion Recovery:
-
- It was suggested that the congestion recovery mechanisms should be mandatory
- in GOSIP, rather than "strongly recommended". It was pointed out that there
-
- is a difference between congestion recovery and congestion avoidance, and
- that only the congestion recovery need be mandatory. After a brief
- discussion this proposal was accepted.
-
- Inclusion of CO/CL indicator in SEL part of NSAP address:
-
- Several people raised concern about the bit in the SEL part of the NSAP
- address which indicates whether the network service is connectionless or
- connection-oriented. It was explained that in some cases, in the absence of
- directory services, an ES which is to initiate communications may have the
- remote NSAP address available, but not know whether to use the
- connectionless or connection oriented network service. By looking at the
- bit in the remote NSAP address, it would know what protocol/service type to
- use. This was described as an interim measure.
-
- This explanation raised the level of interest from mild displeasure to
- serious concern. In particular, it was clear that some people were planning
- to write code which relied upon specific meaning in the SEL fields of remote
- NSAP addresses. Software written with this assumption would never be able
- to interact with any end system which happened to assign the wrong value to
- that bit of the NSAP address (such as non-Gosip OSI-compliant systems, or
- systems implementing future or past versions of GOSIP). We quickly agreed
- that this was undesirable.
-
- NSAP format:
-
- Other than the CO/CL bit in the SEL field, people were quite happy with the
- NSAP format. We agreed that RFC 1069 should be re-written to be compatible
- with GOSIP version 2.0.
-
- NSAP Assignment and Administration:
-
- There was a lengthy discussion about who was to administer NSAPs. Doug
- Montgomery suggested that since they were already setting up administrative
- procedures for the bulk of the Government, perhaps the same procedures
- should be used for the DoD. There was also some talk about whether the same
- procedures should be used for the entire Internet community, including
- educational institutions and government contractors. There was no agreement
- on this last group, except that in general there was no clear distinction
- between what was a government contractor and what was a private company
- (which would be expected to get their assignment from ANSI). Related to this
-
-
-
- 5
- discussion was the issues surrounding the administration of ICD 0005 and ICD
- 0006. Although ICD 0006 is delegated to the DoD (and therefore, part of the
-
- Internet), many felt that all addresses should be registered under ICD 0005,
- and ICD 0006 left empty (or for private military use).
-
- There was also a discussion of the need for guidelines on (i) what sort of
- agencies should be considered an Administrative Authority; (ii) Under what
- conditions should specific grouping of networks be included in one domain,
- versus being split into several domains. We appeared to be in agreement
- that in many cases the specific people who are tasked to set up domain and
- address structures will be folks who do not fully understand the technical
- ramifications of these choices (such as the effect on routing). It was also
- suggested that commercial companies probably have the same need for
- information of value to clients setting up large networks. It was agreed
- that (i) There is a need for such guidelines; (ii) Writing these guidelines
- is beyond the scope of the OSIIWG, although we would like to review and
- comment upon any guidelines intended for the Internet; (iii) This was an
- important issue which should be brought to the attention of the IAB and the
- FRICC, but which did not result in any specific comment to GOSIP.
-
- It was agreed that it would be preferable to describe the address
- administration in a separate document from the NSAP address, rather than
- postpone re-issuance of RFC 1069 in order to include both issues in one RFC.
-
- O/R Names:
-
- We were generally in agreement that the X.400 O/R Names section in Gosip has
- problems.
-
- Priority Processing of PDUs:
-
- The GOSIP 2.0 spec contains a bullet item which could be interpreted to mean
- that in order to conform with GOSIP you HAVE to separate incoming traffic by
- priority before processing the header (which would seem to imply mostly
- processing the header to find the priority, then queueing the packet, then
- re-processing the header). On the other hand, it was pointed out that in
- some specific environments priority forwarding of packets is very important.
- We proposed alternate wording which we feel preserves the possibility for
- individual acquisition authorities to require priority handling of packets
- where appropriate, while correcting the possible mis-interpretation.
-
- Example of use of DoD Management Protocols:
-
- In the introductory section there is a discussion of the need to use
- "Tertiary" sources for protocol specifications (sources which are neither
-
-
-
- 6
- standards nor proposed standards). An example was given of use of DoD
- management standards (designed for use with TCP/IP) for management of OSI
-
- systems. We agreed that this was a poor example, and proposed a better
- example (use of the ANSI MIB along with DIS version of CMIP).
-
- General:
-
- Various folks were tasked with writing up paragraphs describing each item,
- which Ross agreed to type up for submission to NIST.
-
- INTER-DOMAIN ROUTING (Tuesday)
-
- We had a half day for discussion of Inter-domain Routing Protocols, which
- was intended for two purposes: (i) For information purposes, to increase
- understanding of what possibilities are under development; (ii) To determine
- what we want to do short term in the Internet.
-
- Marianne Lepp (chair of the IETF Open Routing Working Group) gave a
- presentation of the inter-domain architecture on which the ORWG is working,
- and presented a schedule for more concrete written architectural and
- protocol specifications. Doug Montgomery gave a presentation of the NIST
- scheme, which ECMA and NIST are bringing to OSI. Finally Jacob Rehkter of
- IBM gave a presentation of the short-term proposal of the Interconnectivity
- Working Group.
-
- We then had a discussion of what to do for short term use in the Internet.
- Yacob Rechkter asked: "How many routing domains do we have currently in the
- Internet?" (obviously the answer is none). He then asked: "How many will
- we have in two years?" (probably not very many). He suggested that the
- number of domains will probably be very small for several years, and that we
- have much more pressing problems. So, why not just use fixed tables for
- now, and in a couple of years re-visit the question (with the benefit of the
- work of the other Internet groups working on this problem for TCP/IP). We
- quickly agreed on this.
-
- There ensued a brief discussion that essentially was of the question "How
- fixed are fixed routing tables, and what might one offer to allow remotely
- updating them". There was no clear conclusion.
-
-
-
- 7
- INTRA-DOMAIN ROUTING (Tuesday)
-
- Dave Oran gave a presentation of the DEC/ANSI intra-domain IS-IS routing
- protocol, with emphasis on the changes made since the older (October 1987)
-
- version. Dave had a hard copy of the brand new updated proposal, which was
- sent to be copied and distributed. The new version of the ANSI IS-IS
- routing spec, which will be submitted to ISO in Sept. 1989 will follow,
- with luck, the following progression through ISO:
-
-
- o DP Jan, 1990
-
- o DIS Oct, 1990
-
- o IS June, 1991
-
-
- GENERAL MEETING (Wednesday)
-
- BSD 4.4 STATUS REPORT
-
- A brief status report on 4.4 BSD was given by Rob Hagens. The ISODE is
- being ported to run over the Wisconsin lower layers. Testing of the now
- complete OSI stack will begin shortly.
-
- ECHO OPTION FOR ISO 8473
-
- Two mechanisms for realizing an 8473 echo request/reply were discussed by
- Rob Hagens: using a SEL value to indicate that a DT pdu should be sent to
- an echo entity, or using a new type code in the pdu itself to distinguish a
- DT from an echo request/reply.
-
- The OSIIWG felt that the use of the SEL is a good short term solution.
- However, the new type field is the best long term solution. The echo draft
- (not yet public) should be edited to suggest that the SEL field be used in
- the short term. Concurrent to this, the new type code should be described
- in detail and submitted to ANSI as a work item.
-
- Finally, the source route option was discussed. Some people would like to
- use it in the echo-request and have it reversed in the echo-reply. Others
- would like it not copied from echo-request to echo-reply. Since the source
- route option is currently incorrectly specified in ISO 8473, it was
- suggested that the best approach is to discourage use of a source route
- option when using an echo facility.
-
- ENCAPSULATION
-
- The OSIIWG agreed that a production encapsulation method was a necessary
- transition aid. EON, as specified in RFC 1070 is insufficient.
-
-
-
- 8
- The act of wrapping and unwrapping CLNP in DoD IP should be performed by
- gateways. The CLNP should run in native mode as far as possible.
-
- There are actually 3 sub-problems:
-
-
- a) The wrapper/unwrappers must know of each other of the purpose of network
- layer routing. b) The wrapper (when acting as a SNDCP for CLNP) must obtain
- the mapping from NSAP address to SNPA (DoD IP address) of the unwrapper. c)
- It is not clear if the CLNP packet should be placed directly into the DoD IP
- data field, or if a small header should be used. The header might contain
- the NSAP/DoD IP address mapping of the wrapper. The general consensus was
- not to include this extra header.
-
- The routing problem (a) is similar to that experienced when X.25 is used as
- an COSNS for CLNP. The group looked to the ANSI IS-IS proposal for support.
- The IS-IS solution does not provide a magic solution. A general opinion of
- the group was that static tables should be used. However, opinions varied
- considerably. The question really becomes: how static is static? Could we
- utilize a network management protocol to adjust static tables? This topic
- requires more discussion.
-
- The method of mapping the NSAP to DoD IP address (b) was not determined.
- Again, the ANSI IS-IS spec. was not helpful. Possibilities include: embed
- the DoD IP address in the NSAP address, use static tables, use an SNPA
- server. This topic requires more discussion.
-
- DIRECTORY SERVICES AND NAMING
-
- Dave Oran gave a presentation on the DEC DNS naming scheme. Karen Sollins
- gave an ad hoc presentation on the X.500 name service.
-
-
-
- 9
-